QRZ! Ham Radio 4/QRZ Ham Radio Callsign Database - Volume 4.iso/digests/digital/940165.txt

Internet Message Format | 1994-11-13 | 24KB

Date: Fri, 27 May 94 04:30:19 PDT
From: Ham-Digital Mailing List and Newsgroup <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: Ham-Digital Digest V94 #165
To: Ham-Digital


Ham-Digital Digest          Fri, 27 May 94       Volume 94 : Issue  165

Today's Topics:
                        DSP questions (3 msgs)
                      NOS with the Baycom Modem
   Pin-out for Tiny-2/Micropower-2 to Radio Shack HTX 202/ICOM 2AT?
                       Probs with Micropower-2
                           Quiet computers
                       VHF Packet net questions

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Ham-Digital Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 26 May 94 19:49:35 GMT
From: [e-mail]
Subject: DSP questions
To: [e-mail]

Is anyone out there aware of any experiments done in the use of DSP to
produce simulated spatial displacement of audio tones as a function of
their frequency?  What I have in mind is being able to spread a pile-up
by having the lower-frequency tones appear to be on the right and the
higher ones on the left, in an experiment to see whether that helps pick
out individual signals.  Could such a thing be implemented using an
ordinary sound-card with stereo outputs as the interface?

73, Pete
[e-mail]
NOTE: New Address

------------------------------

Date: 26 May 1994 21:16:54 GMT
From: ihnp4.ucsd.edu!swrinde!gatech!news-feed-1.peachnet.edu!news.duke.edu!eff!news.kei.com!ssd.intel.com!chnews![e-mail]
Subject: DSP questions
To: [e-mail]

Peter G. Smith ([e-mail]) wrote:
: Is anyone out there aware of any experiments done in the use of DSP to
: produce simulated spatial displacement of audio tones as a function of
: their frequency?  73, Pete  [e-mail]

Just such an analog design appeared in one of the amateur pubs a couple
of years ago. It was a low-pass filter to the left ear and a high-pass
filter to the right ear. It could easily be done with a soundcard.

73, KG7BK, [e-mail]

------------------------------

Date: 27 May 1994 01:52:47 GMT
From: ihnp4.ucsd.edu!agate!darkstar.UCSC.EDU!news.hal.COM!olivea!inews.intel.com!mipos2![e-mail]
Subject: DSP questions
To: [e-mail]

In article <2s33k6$[e-mail]> [e-mail] (Cecil A. Moore -FT-~) writes:
>Peter G. Smith ([e-mail]) wrote:
>: Is anyone out there aware of any experiments done in the use of DSP to
>: produce simulated spatial displacement of audio tones as a function of
>: their frequency?  73, Pete  [e-mail]
>
>Just such an analog design appeared in one of the amateur pubs a couple
>of years ago. It was a low-pass filter to the left ear and a high-pass
>filter to the right ear. It could easily be done with a soundcard.
>
>73, KG7BK, [e-mail]
>
Ah, but to get spacial placement, what you want to do is alter
the phase delay to each ear and keep the amplitude flat.  The
stereo effect is a function of phase, not amplitude.  Each channel
should be an all-pass function, with symetrically opposite group
delay curves.  Several years ago there was an analog circuit published
in, I believe, Ham Radio that did just that.

Some time in the early 80's, like maybe '83, there was an issue of
either IEEE Spectrum or maybe the Proceedings of the IEEE that was an
anniversary issue of some kind.  The contents were seminal
papers in several areas, one of which was a great paper on
stereo audio and how it worked.  This was when "Stereo Hi-Fi"
was new and nifty stuff.  (BTW, the other papers in the issue
are equally nifty.)  Anyway, go read the stereo paper and the
silliness of using amplitude to get spatial placement will be
quite apparent.

The DSP version should be pretty simple -- Do an all-pass with
linear group delay on one channel, and simply delay the other
channel to place middle tones in the middle of space.

73, Dave NG0X
[e-mail]

------------------------------

Date: Fri, 27 May 94 02:40:39 GMT
From: ihnp4.ucsd.edu!library.ucla.edu!csulb.edu!csus.edu!netcom.com!netcomsv!skyld![e-mail]
Subject: NOS with the Baycom Modem
To: [e-mail]

Jeff Please forward this to the appropriate newsgroup/individual
                          TCP/IP WITH NO TNC
                        By: Mike Hooper, KF6PU
  TNCs run in the kissmode and SCC cards such as the DRSI PCPA have long
been the staple of most TCP/IPers running NOS and Net versions of the KA9Q
Internet Suite of Protocols. There is a much less expensive and more
elegant solution for a 1200 baud hardware interface.
 "Baycom" style modems have enjoyed international popularity for some time
now among those running packet software that employs the "software tnc"
approach. Baycom, PMP, and Eskay Packet (SP) V6.10 with the TFPCX driver
are very popular.
 Most Baycom style modems are designed around either the AMD 7910 "World
Chip" IC , Texas Instruments TCM 3105, or the EXAR 2206/2211 pair. Most
commercial TNCs use these chips for the modem section. For example, the
AEA PK-88 uses the AMD 7910, The Kantronics KAM and KPC-4 use the TCM 3105
for VHF-UHF ports and the MFJ 1270/1274 use the EXAR pair. Few external
parts are required for these modems and they are easy to construct. The
TCM 3105 modem can be built for under $25.00 and can be built so small as
to fit into a DB25 shell.
 Thanks to the efforts of Pawel Jalocha, SP9VRC ([e-mail])
([e-mail]) a packet driver conforming (to a sufficient
extent) to the "FTP packet driver specification" has been developed that
serves as an interface between application software (e.g. KA9Q NOS) and a
modem connected to the RS232 port (e.g. Baycom modem). This driver along
with documentation and accessory files have been distributed in this
country under the filename "AX25DRV.ZIP" .  Be sure to use the January 4,
1993 version as prior releases have bugs.
 Jawel's packet driver enables the use of unsquelched audio as the driver
is able to deliver "channel busy" status by analyzing incoming data.
 The driver is loaded into memory before NOS is run. The utility
"TERMIN.COM" is used to remove the driver from memory when one exits from
NOS. Below is a batch file that sets up the driver for use on COM2 with
NOS :
          @echo off
          c:
          cd\net
          ax25 -b1200 -B2f8 -I3p -cd -h350
          nos.exe
          termin.com
          cls
 The switches invoked with ax25.com specify: 1200 baud, COM2, IRQ priority
(given to IRQ 3 in this example), carrier detect option, and txdelay.
Slottime and persist default to 100 msec. and 64 but are adjustable with
the -s and -p switches. The software interrupt defaults to 0x60 but is
adjustable from 60 through 63 with the -i switch. Carrier detect threshold
and TXtail are also adjustable with the -T and -t switches. A switch need
not be specified if the default value is used.
 Within AUTOEXEC.NOS is the following attach statement (your version of
NOS must be compiled with the attach packet hardware interface option):
          attach packet 0x60 144 5 256
 I have been using this driver with both the WG7J and KB7YW versions of
NOS for several weeks. My system utilizes three hardware interfaces two of
which are handled by a DRSI card. During this period I have had the
opportunity to use a KAM (v6.0), PK-88, and a PK-232 with the TAPR DCD mod
and in no case have I found these superior to a TCM 3105 modem used with
Jawel's ax25 driver. The driver does not work well on an XT clone.  My
computer is a 386-33 SX using a pair of 16550 AFNs. I find it useful to
reset the computer before running NOS to "clear" the comports.
 Work is currently in progress on adapting the G3RUH 9600 modem for use
with the AX.25 driver. Potential problems concerning interrupt latency
issues may complicate matters. If success is achieved it would
substantially reduce the cost of running TCP/IP at 9600 baud.
 -73- kf6pu@wb6ymh.#soca.usa
[e-mail]

73 es GE from Jeff













----------------


 Amateur: WA6FWI@WA6FWI.#SOCA.CA.USA.NOAM | "You have a flair for adding
Internet: [e-mail]        |  a fanciful dimension to any
 US Mail: PO Box 4425 Carson, CA 90749    |  story."
   Phone: [phone]                |           Peking Noodle Co.

Hate "Green Card Lottery"? Want to help curb ignorant crossposting on Usenet?
E-mail [e-mail] for more information, or read news.groups.

------------------------------

Date: 26 May 1994 15:28:23 GMT
From: ihnp4.ucsd.edu!usc!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!icaen![e-mail]
Subject: Pin-out for Tiny-2/Micropower-2 to Radio Shack HTX 202/ICOM 2AT?
To: [e-mail]

Will somebody who's hooked their PacComm Tiny-2 OR Micropower-2 TNC to
either a Radio SHack HTX-202 or another ICOM 2AT-compatible HT please
e-mail me the wiring configuration?  I've got a Micropower-2 but the
company is currently out of manuals so I don't know how to get it
wired.

--
__  /|  | Doug Renze, N0YVW       |
\'o.O'  | [phone]         |             Amateur Radio:
=(___)= | [e-mail]  |      Bringing the World Together
   U    |                         |

------------------------------

Date: 26 May 1994 15:17:00 GMT
From: ihnp4.ucsd.edu!library.ucla.edu!europa.eng.gtefsd.com!howland.reston.ans.net!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!icaen![e-mail]
Subject: Probs with Micropower-2
To: [e-mail]

Ergle.  I'm having a prob that I hope really isn't one...
    I've got a Micropower-2 TNC hooked up to my computer, but don't have
the radio hooked up yet (haven't got the cables and can't quite figure out
how to wire it to the HTX-202/ICOM 2AT config).  Well, I decided to switch
it on today to play around with the commands and...nothing.  I've done this
before and gotten a nice startup screen followed by the "cmd>" prompt, but
today I got absolutely zilch, though it does echo characters and character
returns back to the screen so I don't really think anything's fried.  Am
I in some sort of weird mode somehow, and how can I get it back out of it?
    Or am I f***ed?

--
__  /|  | Doug Renze, N0YVW       |
\'o.O'  | [phone]         |             Amateur Radio:
=(___)= | [e-mail]  |      Bringing the World Together
   U    |                         |

------------------------------

Date: Thu, 26 May 1994 13:30:05 GMT
From: ihnp4.ucsd.edu!library.ucla.edu!csulb.edu!csus.edu!netcom.com![e-mail]
Subject: Quiet computers
To: [e-mail]

Here's a different subject...

What specific brands/models of PCs have folks found to be particularly
good or bad with regard to RF hash generated, and suseptability to
RF fields?

I'll start: my Compudyne 38625SXL (Twinhead) notebook is pretty good as far
as generating noise, below 10.15 Mhz. On 20 meters, and up, it's
pretty much of a disaster, growing worse as the frequency increases,
even when run on battery power and equipped with split ferrites on
all external cables. The LCD display seems to be part of the problem.

On the plus side, it tolerates fields which are equal or greater to
what the PK232 can take.

Greg

------------------------------

Date: 26 May 1994 21:53:10 GMT
From: ihnp4.ucsd.edu!swrinde!gatech!nntp.msstate.edu!Ra.MsState.Edu![e-mail]
Subject: VHF Packet net questions
To: [e-mail]

We are currently trying to get a VHF packet net started to increase the
general use of packet in our area.  We have been having trouble deciding
what format to use to get everyone together.  We have considered an unproto
via 2 area digis, connecting to a net/rom (I think) node and using a talk
feature (which sends each user's packet to everyone individually), and are
out of ideas of a smooth way to accomplish this.  There will be some people
who will have to digipeat to get into our area.  Any and all ideas will be
welcome, and if anyone has such a beast currently running, I would love to
hear from you.

Thanks in advance,
Craig

--
 ---------------------------------------------------------------------------
 Craig Lindsey - KC5AUG       | My politics are simple: Always go right. If
 Internet: [e-mail]| you go left, you can never go right, and if
 Bitnet:   [e-mail]| you go right, you never go wrong.  -Grizzard

 Packet: [e-mail]

------------------------------

Date: Thu, 26 May 1994 14:47:25 GMT
From: ihnp4.ucsd.edu!pacbell.com!amdahl!juts.ccc.amdahl.com![e-mail]
To: [e-mail]

References <[e-mail]>, <2s0hvr$[e-mail]>, <[e-mail]>
Reply-To : [e-mail] (Sid Boyce)
Subject : Re: >9600 bps packet (was: Re: 9600 bps radio modems)

Anonymous ftp col.hp.com /hamradio/packet/n6gn/uwavelink(multi megabaud)

ftp.ucsd.edu has stuff .... tapr9600.mod and 96man.txt if you are
looking for 9600 baud info.

73    Sid Boyce ... G3VBV .... Amdahl(UK) ... G3VBV@GB7BHM.#29.GBR.EU

------------------------------

Date: Thu, 26 May 1994 21:54:03 GMT
From: ncrgw2.ncr.com!ncrhub2!ranger!cn2935.DaytonOH.NCR.COM![e-mail]
To: [e-mail]

References <[e-mail]>, <[e-mail]>, <2s0hvr$[e-mail]>
Subject : Re: >9600 bps packet (was: Re: 9600 bps radio modems)

In article <2s0hvr$[e-mail]> [e-mail] (Val Kartchner) writes:
>In article <[e-mail]> [e-mail] (Bob Donnell) writes:
>>I'm suprised John didn't mention it - the new TAPR NETSIG mailing list is
>>heavily involved in discussing 9600 (and faster) modem/radio issues.

>How do I read this mailing list?  Is it a packet-only mailing list, or
>is it available to Internet users?

ObPlug:

The TAPR NetSIG mailing list is devoted to discussion of amateur packet radio
networking issues.  It's not limited to hardware discussions, though there's
plenty of that going on right now.

To subsrcribe, send a message to [e-mail] with "join netsig" in
the body.  To submit messages, send to [e-mail].

Note:  the list has been very busier -- busier than we had ever hoped -- and
as a result we recently had to change homes, and there have been a few bugs in
the system.  Please bear with us.

John   AG9V
[e-mail]

PS -- No, I don't know much about the NCR Wavelan stuff, despite my address.
I wish I did, but I've never been able to get my hands on any surplus units.

------------------------------

Date: Thu, 26 May 1994 21:46:29 GMT
From: ncrgw2.ncr.com!ncrhub2!ranger!cn2935.DaytonOH.NCR.COM![e-mail]
To: [e-mail]

References <[e-mail]>, <[e-mail]>, <[e-mail]>rh
Subject : Re: 9600 bps radio modems

In article <[e-mail]> [e-mail] (Bob Donnell) writes:

>Also, as a side note, when we've done testing here on link reliability we
>usually are using the 'ping' feature of tcp/ip and NOS to do the testing.
>We run 'datagram' (unconnected) mode and usually use 200-400 byte packets.
>I have noticed that with two analog modems (TAPR on one end, PK-900/PK-96/
>TAPR/G3RUH on the other) that the best ping response I can get is about 95%
>through our TAPR bit-regen modem equipped 2M repeater.  This is over about a
>45 mile line-of-site path.  Switching to a DSP-2232 will improve the ping
>return rate to about 98-99%.  Kudoes to N4HY.  Note that due to atmospherics
>(ducting, etc) and the fact that the repeater is at about 5000 feet we have
>times when the path to the repeater is poor to unusable, too.  This is part
>of why our next generation of repeaters are at low altitude sites, mostly
>cell sites.

Here's another data point:  we do our testing on the 19.2 repeater the same
way, via ping, usually with a 256 byte packet and 3 or 4 second interval.

We also see ping hit rates of about 95% at best, 85% or so at worst,
through the repeater (with reasonable but not pile-driver paths, and some
other activity on the system).  In bench tests, we get up to 98-99 percent.

The non-returns generally are about evenly spaced, with occasional clusters of
two or three drops in a row.  Even over very long tests, we almost never see a
run of more than 100 pings without a drop.

This is using the D4-10 as an RF modem, directly driven by modem disconnect
header or PI card.  No scrambler.  And, unfortunately, no bit regen (yet).
I'm very interested in seeing whether adding bit regen is going to improve
error rates generally, or only help on marginal signals.  We're hoping to add
a regen later this summer (once I can get a TAPR 9600 modem kit to butcher).

John   AG9V
[e-mail]

------------------------------

Date: 26 May 1994 19:28:36 GMT
From: ihnp4.ucsd.edu!swrinde!gatech!howland.reston.ans.net!spool.mu.edu!torn!hermes.acs.ryerson.ca!ee.ryerson.ca![e-mail]
To: [e-mail]

References <2q8erk$[e-mail]>, <[e-mail]>, <[e-mail]>
Subject : Re: PacketRadio forLinux with Baycom ??

Daniel T Senie ([e-mail]) wrote:
: In article <[e-mail]> [e-mail] (Kevin Sanders) writes:
: >In article <2q8erk$[e-mail]> [e-mail] (Donald Jeff Dionne) writes:
: >>
: >>said that, however, there is a driver for Linux that does audio over the
: >>pc speaker using a timer and some sort of PWM, and it works unless the
: >>machine is busy with disk I/O or the like.....  If you don't mind packet
: >>loss when the machine is busy, and the machine comming to a halt when
: >>packet is going on (as it does with the pc speaker), then perhaps I'm
: >>wrong and it's worth a try.
: >
: >I experimented with a similar project; I wrote a driver which speeds up
: >the system clock and samples one of those AEA fax interface units, to
: >try to get HF fax running under Linux.  I found that the IDE disk driver
: >(at least for Linux 0.99.10 or so) disabled interrupts for long enough
: >to skew my picture by 5-10% of the width each time a sync() occured :-(
: >
: >I did not notice any other delays besides the IDE disk.  I now have
: >a SCSI-based system and it may not exhibit this problem.  I also heard
: >that the Linux IDE driver has been improved lately and does not disable
: >interrupts for as long as it used to.

: Actually, many of the SCSI adapters, such as the 1542 from Adaptec, are
: BUS MASTER devices. This means that the main CPU cannot get on the bus
: to service interrupts at all during some periods. Bus mastering is a
: desirable way to improve performance for DMA on disk controllers. Expect
: to see lots more bust mastering on the newer bus achitectures.


No, I have a 1542 in my Linux box, and it does not steal enough cycles to
cause a problem with anything :-)

: >
: >Bottom line is, you must use the timer interrupt for polling as it is
: >the highest priority; and also you had better have as good (or better)
: >an understanding of the behavior of every driver, wrt locking out
: >interrupts, as the people who wrote them.  It's probably safest to
: >determine this empirically, by cranking up the tick speed and counting
: >the ticks for a few hours.  Beat on the system as hard as you can during
: >this time, and see if you missed any ticks (by checking against a
: >real clock).  You should be able to nail down the maximum tick rate
: >permissible and then decide if this is fast enough sampling for your
: >application.


Yes.  With a 386dx33, you can get 20k interrupts per second.  That's
an order of magnitude more than needed.  On a 486dx2-66, 70k.  On
even a 386dx33, the impact on system performance would be acceptable,
perhaps even go un-noticed!  Seems I was wrong... this is do-able.

: Bottom line is, a PC's main processor makes a terrible SCC controller.
: the BAYCOM and PMP approaches are neat little hacks that really can
: only work when you're talking about a DOS based machine that can run
: without any preemption. Windows, Unix, Linux, OS/2, and most operating
: systems have preemptive scheduling. Sure you can tweak them to handle
: the timing needed for a $50 BAYCOM modem, though you run the risk of
: having to spend considerably more on enough computer horsepower to
: hit the timing windows, and enough of your time to make it non-cost
: effective.

You are right, of course.  It's not a good solution, but cost effective?
I think so.  No, there's no profit to be make, but once the code is
written, packet under Linux is much more affordable for those that don't
have (or want to spend) the extra for a real TNC.

: What I find odd, is that spending another $50 to get to $100 and buy a
: real TNC, that can handle the synchronous communications of the packets
: on the air, handle the HDLC framing, etc. is MUCH simpler than trying
: to hack a multi-threaded or multi-processing OS into being able to
: handle a BAYCOM modem. Sometimes the hardware solution is cheaper...

It's only cheaper the first time.  If it could be made to work, BAYCOM
style modems for Linux would open up packet to new users for far less
than any other solution.

: >
: Dan N1JEB
: --
: ---------------------------------------------------------------
: Daniel Senie                 Internet:     [e-mail]
: Daniel Senie Consulting                    [e-mail]
: 508-779-0439                 Compuserve:   74176,1347

------------------------------

Date: Thu, 26 May 1994 09:49:03 GMT
From: ihnp4.ucsd.edu!swrinde!pipex!uknet!icsbelf![e-mail]
To: [e-mail]

References <[e-mail]>, <[e-mail]>, <2s0hvr$[e-mail]>
Subject : Re: >9600 bps packet (was: Re: 9600 bps radio modems)


Is there an ftp archive or, even better, a WWW server for information on
high speed packet? Perhaps someone would like to run a server at their site?

We'll be doing some 9600 links here in GI soon, and I'm hoping to get some
info to help me get things going.

-mark
--
Mark Willis                   Internet:   [e-mail]
ICS Computing Group Ltd.      Packet:     GI0PEZ@GB7TED.#63.GBR.EU
Belfast                       AmprNet:    44.131.15.3
Northern Ireland              CompuServe: 100317,3025

------------------------------

End of Ham-Digital Digest V94 #165
******************************